引言

最近我在深入學習 Kubernetes Administration。
公司本身用的是 Azure Kubernetes Service（AKS），因為 AKS 幫我們代管了很多東西，例如控制平面與基礎設施層，所以我平常在生產環境中要「直接動手管理」的東西其實不多。大多數時候，我的日常就是更新應用、部署新版本，或者查看 Pod 與 Service 的狀態。

一直以來，我對管理 Kubernetes 資源的方式幾乎沒有多想。對我來說，就是準備好 YAML 檔案，然後一句 kubectl apply -f 全部搞定，沒有特別去思考背後的操作模式。直到最近在準備 Kubernetes 認證與管理員相關知識時，我才發現原來管理 Kubernetes 資源有兩種主要的方式——Imperative（命令式） 與 Declarative（宣告式）。
這個發現讓我重新審視自己日常的操作方式，也更理解 GitOps 為什麼是現在的趨勢。

1. 什麼是 Imperative 與 Declarative

• Imperative（命令式）：直接告訴系統「你要做什麼」，一步一步描述動作，例如建立 Pod、刪除 Service、調整副本數。
• Declarative（宣告式）：描述「我要的結果」，由系統決定要做哪些步驟來達成該狀態。

對應到 Kubernetes：

• Imperative：kubectl create、kubectl delete、kubectl set
• Declarative：kubectl apply -f，或透過 GitOps 工具同步狀態

2. Imperative 的特點與範例

kubectl run nginx --image=nginx
kubectl scale deployment nginx --replicas=3

優點：快速、直覺、不需 YAML 檔案。

缺點：無版本控制、不易追蹤、環境一致性差。

3. Declarative 的特點與範例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

kubectl apply -f nginx-deployment.yaml

優點：可版本控制、易複製、適合自動化、可審查。

缺點：需撰寫 YAML、臨時修改較慢，而且 不是 apply 後就可以高枕無憂——有些屬性（例如 priorityClass）不能直接套用變更，可能需要刪除重建資源才能生效。

4. Imperative vs Declarative 對照表

5. 混合使用的現實場景

在 AKS 的日常管理中：

• Imperative：快速調整副本數、臨時 debug
• Declarative：版本管理、部署新功能

例：

kubectl scale deployment my-app --replicas=5
kubectl apply -f my-app-deployment.yaml

這樣能避免環境脫管。

6. GitOps 與 Declarative 的延伸

GitOps 工具（如 ArgoCD、Flux）可：

1. 將 YAML 存放於 Git
2. 自動同步狀態
3. 偵測並回滾未授權變更

優勢：可追溯、自動化、一致性。

7. 總結與反思

Imperative 與 Declarative 各有優劣。建議：

• 開發測試用 Imperative
• 生產用 Declarative

8. Reference

• 官方文件

Declarative 雖能讓 Kubernetes 自動維護狀態，但並非 apply 後就什麼都不用管，還需要了解其限制與例外情況，才能確保系統真正穩定。